home *** CD-ROM | disk | FTP | other *** search
/ C/C++ Interactive Reference Guide / C-C++ Interactive Reference Guide.iso / c_ref / csource5 / 355_01 / slk1.exe / SPP.DOC < prev    next >
Text File  |  1991-06-11  |  5KB  |  82 lines
  1. THE THEORY OF OPERATION OF SPP
  2.  
  3. SPP is a strange combination of a one pass C compiler and a file copying
  4. program.  With the exception of about 20 lines of code, the two programs are
  5. completely independent!
  6.  
  7. The job of the compiler is to know the types of all functions and variables,
  8. to insert entry macros before the first executable statement of a function, to
  9. replace return instructions by exit macros and to insert exit macros at the
  10. end of every function if flow could fall off the end of the function.  In
  11. order to do this, all include files must be processed and all macros must be
  12. correctly expanded.
  13.  
  14. The job of the file copying program is to copy all the characters of the main
  15. file while allowing Sherlock macros to be inserted and return statements to be
  16. revised.  Characters from included files are not copied and an option is
  17. provided to eliminate unnecessary white space, including comments.  The file
  18. copier is bullet proof:  it will, for instance, correctly copy a Pascal program
  19. even though the parser becomes (as it should become) hopelessly confused.
  20.  
  21. The compiler is based on a recursive descent parser, found in PAR.C, DCL.C and
  22. EXP.C.  The only complication here is that the parser accepts both K&R C and
  23. ANSI Standard C.  Oh yes, the parser also accepts some Borland and Microsoft
  24. extensions.  To add your own extensions, change the function allow_mkeys.
  25.  
  26. The parser calls the get_token() routine to get a stream of C tokens.
  27. The get_token routine handles all preprocessor directives and macro expansion
  28. transparently to the parser.  This has always been the part of SPP where the
  29. most real bugs lurked.  Be warned.  The files SPP.C, DEF.C, DIR.C, TOK.C and
  30. UTL.C contain the heart of the token processing routines.  The file MST.C
  31. contains the macro symbol table used to record and expand macro definitions.
  32.  
  33. The parser calls semantic routines in SEM.C.  There are three kinds of
  34. semantic routines:
  35.  
  36. 1.  The functions whose names start with sd_  (for semantic declaration)  keep
  37. track of the declared types of all functions and variables.  The file ST.C
  38. contains the symbol table used by the semantic routines.
  39.  
  40. 2.  The functions whose names start with sf_ (for semantic flow) keep track of
  41. the possible flow of control through the executable statements in a function.
  42. These functions maintain a "flow stack" telling whether flow could ever fall
  43. through the end of the current statement.
  44.  
  45. 3.  The functions whose names start with so_ (for semantic output) create the
  46. additional macro calls that are generated by SPP.  Because of the one pass
  47. nature of SPP, calling these routines at exactly the right time is tricky.
  48.  
  49. Header files:  The values of tokens used throughout SPP are defined in enum.h.
  50. The definitions of are global variables are found in glb.h.  The prototypes of
  51. all globally visible functions are found in tmp.h.  All other constants are
  52. found in spp.h.
  53.  
  54. SPP is designed in separate modules.  Variables and constants that are used
  55. only by a single module are declared static so that they are invisible outside
  56. the file in which they are defined.   The partitioning of SPP into separate
  57. files was intended to reduce the number of global variables.  In my opinion,
  58. this aspect of the design of SPP has been a complete success.
  59.  
  60. The file SYS.C contains low level routines that might have to be rewritten
  61. should SPP be ported to another machine or operating system.  Even in the days
  62. of the ANSI standard, the SYS.C module is quite useful.
  63.  
  64. One of these low level routines is sysnext(), which returns the next character
  65. from the current input file.  This is the most often called routine in the
  66. whole program, and has been tweaked to make it run fast.
  67.  
  68. The file copier program operates inside sysnext(), at the lowest level of the
  69. whole program.  As characters are returned from sysnext(), they are placed in
  70. the hold buffer.  Characters are not placed in the hold buffer if they come
  71. from an included file or from a macro expansion.
  72.  
  73. The hold buffer is output when syshflush() is called, or emptied (either
  74. partially or completely) without being output when syshkill() or syshnldel()
  75. are called.  These calls to syshflush(), syshkill() and syshnldel() form the
  76. interface between the file copier and the parser.  Although only 11 calls to
  77. these routines appear throughout the parser, getting these 11 calls right is
  78. tricky--syshflush() must be called often enough so that the hold buffer never
  79. overflows, but syshflush() must never be called when a Sherlock macro may
  80. have to be output, since either syshkill() or sysnldel() would be called
  81. instead.
  82.